Gestión y análisis de riesgo - Sprint 1
Universidad de Sevilla
Escuela Técnica Superior de Ingeniería Informática
Grado en Ingeniería Informática – Ingeniería del Software
Curso: 2024 – 2025
Fecha: 08/03/2025
Versión: v1.2
Grupo de prácticas: G1
Nombre del grupo de prácticas: ISPP - Grupo 1 - Holos
- María del Mar Ávila Maqueda
- Joaquín González Ganfornina
- Nerea Jiménez Adorna
- Juan del Junco Obregón
- Miguel Ángel Gómez Vela
- Juan Antonio Moreno Moguel
- María del Carmen Barrera Garrancho
- Daniel Guedes Preciados
- Julia Virginia Ángeles Burgos
- Javier Muñoz Romero
- Juan Núñez Sánchez
- Nicolás Pérez Gómez
- Francisco Pérez Lázaro
- Celia Aguilera Camino
- Gabriel María Vacaro Goytía
- Ignacio Warleta Murcia
- José María Portela Huerta
Responsables:
| Miembro | Responsabilidad |
|---|---|
| Juan del Junco | Redactor |
| María del Mar Ávila | Revisora |
Repositorio: GitHub - Holos-INC
Control de Versiones
| Fecha | Versión | Descripción | Autor |
|---|---|---|---|
| 23/02/2025 | v1.0 | Creación de documento | José María Portela |
| 08/03/2025 | v1.2 | Modificación del documento | Juan del Junco Obregón |
| 13/03/2025 | v1.2 | Modificación de la portada | María del Mar |
Índice de Contenidos
- Introducción
- Escala de Impacto y Probabilidad en la Gestión de Riesgos
- Tabla de Riesgos
- Tabla de Seguimiento de Riesgos
1. Introducción
El análisis de riesgos es un proceso fundamental en la gestión de proyectos que permite identificar, evaluar y planificar posibles eventos o situaciones que podrían afectar el éxito del proyecto. En este análisis se han identificado diversos riesgos que podrían impactar en el desarrollo, la ejecución y los resultados del proyecto.
2. Escala de Impacto y Probabilidad en la Gestión de Riesgos
-
Probabilidad de Ocurrencia
| Valor | Nivel de probabilidad | Descripción |
|---|---|---|
| 1 | Muy Baja | Es muy poco probable que ocurra. Solo se daría en circunstancias excepcionales. |
| 2 | Baja | Baja probabilidad de que se materialice, pero no puede descartarse completamente. |
| 3 | Media | Posibilidad moderada de que ocurra, dependiendo de las circunstancias. |
| 4 | Alta | Existe una alta probabilidad de que el riesgo ocurra, podría mitigarse con acciones preventivas. |
| 5 | Muy Alta | Casi seguro que el riesgo ocurra si no se toman medidas. |
-
Impacto del Riesgo
| Valor | Nivel de impacto | Descripción |
|---|---|---|
| 1 | Mínimo | El impacto en el proyecto es insignificante y no afectará su desarrollo normal. |
| 2 | Bajo | Puede generar pequeñas dificultades, pero no afecta significativamente la entrega del proyecto. |
| 3 | Medio | Puede causar retrasos o complicaciones en una parte del proyecto, pero es manejable con acciones correctivas. |
| 4 | Alto | Puede impactar de manera significativa el desarrollo del proyecto, generando retrasos importantes o sobrecostes. |
| 5 | Crítico | Afecta gravemente el proyecto, pudiendo causar su fracaso total o un impacto severo en los objetivos principales. |
-
Factor de Riesgo
El factor de riesgo se calcula multiplicando la Probabilidad × Impacto. Este valor ayuda a determinar la prioridad del riesgo y su nivel de criticidad.
-
Niveles de Prioridad
| Prioridad | Nivel de Urgencia | Descripción |
|---|---|---|
| 1 - Crítica | Extremadamente alta | Requiere atención inmediata. Puede detener el proyecto o causar su fracaso si no se gestiona adecuadamente. |
| 2 - Muy Alta | Urgente | Puede tener un impacto grave en los plazos o costos del proyecto. Necesita acciones de mitigación inmediatas |
| 3 - Alta | Alta | Riesgo significativo que debe ser monitoreado continuamente para evitar problemas. |
| 4 - Considerable | Importante | Puede causar retrasos o impactos moderados en el proyecto si no se maneja correctamente. |
| 5 - Media-Alta | Necesita seguimiento | Se debe gestionar de forma proactiva, pero es manejable si se siguen las estrategias de mitigación. |
| 6 - Media | Moderada | Impacto menor en el proyecto, pero se deben tomar medidas preventivas. |
| 7 - Baja | Poco relevante | Riesgo poco probable o con impacto reducido. No es una prioridad alta. |
| 8 - Muy Baja | Irrelevante | Es un riesgo menor con impacto casi insignificante. Solo se gestiona si se materializa. |
| 9 - Mínima | Despreciable | Impacto y probabilidad extremadamente bajos. Prácticamente no requiere gestión. |
| 10 - Insignificante | Sin relevancia | No representa un peligro real para el proyecto, su impacto es mínimo o nulo. |
3. Tabla de Riesgos
A continuación se presenta una tabla que resume los principales riesgos, su impacto y probabilidad, así como las medidas de contingencia que se han diseñado para mitigar o manejar cada uno de estos riesgos.
| ID | Riesgo | Impacto | Probabilidad | Factor | Prioridad | Mitigación del Riesgo |
|---|---|---|---|---|---|---|
| R1 | Cambios frecuentes en el alcance y nuevos requisitos durante el desarrollo | 3 | 2 | 6 | 5 | Implementar un proceso de gestión de cambios y asegurar revisiones periódicas |
| R2 | Requisitos incompletos o erróneos | 3 | 2 | 6 | 5 | Asegurar que los requisitos estén bien definidos y aprobados antes del inicio del proyecto; revisión continua. |
| R3 | Problemas de cohesión y motivación del grupo | 3 | 2 | 6 | 4 | Reuniones de equipo frecuentes, retroalimentación constante, reconocimiento de logros y mantener un ambiente positivo. |
| R4 | Dificultades con la integración y compatibilidad tecnológica | 2 | 3 | 6 | 5 | Planificación de pruebas de integración, pruebas de compatibilidad regulares y uso de herramientas de integración. |
| R5 | Retrasos en actividades claves | 4 | 2 | 8 | 2 | Uso de herramientas de gestión de proyectos para hacer un seguimiento continuo y ajustar plazos. Además de la reasignación de tareas en caso de sobrecarga o bloqueos. |
| R6 | Errores en la planificación del presupuesto | 2 | 2 | 4 | 7 | Revisión periódica del presupuesto, establecimiento de un margen de contingencia y ajuste continuo. |
| R7 | Problemas de seguridad en la aplicación | 3 | 2 | 6 | 4 | Auditorías de seguridad periódicas, uso de buenas prácticas de desarrollo seguro y actualizaciones constantes. |
| R8 | Falta de pruebas y validaciones | 2 | 3 | 6 | 5 | Implementar pruebas exhaustivas, incluyendo pruebas de carga y escalabilidad. |
| R9 | Mala calidad del código | 2 | 1 | 2 | 8 | Implementar revisiones de código regulares, estándares de codificación y usar herramientas de análisis |
| R10 | Insatisfacción de los usuarios piloto | 4 | 2 | 8 | 3 | Recopilación activa de comentarios y retroalimentación, ajustes en base a los comentarios de los usuarios piloto. |
| R11 | Baja productividad del equipo | 3 | 1 | 3 | 7 | Identificar y abordar las causas de baja productividad |
| R12 | Documentación deficiente | 2 | 2 | 4 | 6 | Priorizar la creación y actualización de la documentación técnica y de proyecto de manera continua. |
| R13 | Miembros del proyecto deciden dejar el proyecto | 3 | 1 | 3 | 7 | Abordar proactivamente las preocupaciones del equipo. |
| R14 | Falta de capacidades técnicas o preparación insuficiente | 1 | 3 | 3 | 7 | Dejar tiempo para que los miembros del equipo vean tutoriales y cursos sobre las tecnologías que no conocen. |
| R15 | Falta de comunicación entre equipos de Backend y Frontend | 4 | 4 | 16 | 2 | Establecer reuniones periódicas entre los equipos y coordinar entregas con integración continua. |
| R16 | Usuarios pilotos no responden | 3 | 4 | 12 | 3 | Implementar recordatorios automáticos, incentivar la participación y diversificar las fuentes de feedback. |
4. Tabla de Seguimiento de Riesgos
| ID | Explicación | ¿Sigue vigente? | Acciones tomadas |
|---|---|---|---|
| R15 | Los equipos de Backend y Frontend trabajaron por separado sin coordinarse, lo que resultó en problemas de integración. Ahora falta conexión entre el frontend y el backend, generando retrasos y necesidad de refactorización. | Sí | Se han creado reuniones de sincronización y las nuevas tareas se asignarán en parejas (un desarrollador de Backend y uno de Frontend) para garantizar la conexión entre ambos. |